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1.0 INTRODUCTION AND SUMMARY 

The purpose of this report is to document the test plan and test 
procedures to be used in the verification and validation of the software 
being implemented in the Mission Planning Processor Working Model program. 
The Mission Planning Processor is a user oriented tool for consumables 
management and is part of the total consumables subsystem management con- 
cept presented in Reference 1. The detailed requirements for the Mission 
Planning Processor are presented in Reference 2. The working model will be 
developed from a subset of these requirements. An overview of the working 
model is presented in Section 2. 

Execution of the test plan will comprehensively exercise the working 
model software. An overview of the test plan, including a testing schedule, 
is presented in Section 3. The test results will be published on completion 
of testing. 

The working model will be tested at the unit, module, and system 
levels. The test plan for each level is discussed in Sections 4, 5, and 6, 
respectively. 

The working model results will be validated using known consumables 
requirements previously generated by NASA/JSC/MPAD personnel using detailed 
consumables analysis models. The criteria used to validate the working 
model results for each consumables subsystem are presented in Section 6.2. 
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2.0 OVERVIEW OF THE WORKING MODEL 


2.1 PURPOSE 

The working model of the Mission Planning Processor will be developed 
in order to: 

a) Demonstrate the validity of the consumables subsystem manage- 
ment concept as presented in Reference 1. 

b) Demonstrate the validity of the Mission Planning Processor 
algorithms presented in Reference 2. 

c) Provide a tool for consumables analysis flight planning of 
scheduled Space Shuttle missions. 

2.2 SCOPE 

The detailed requirements for the Mission Planning Processor are 
presented in Reference 2. The working model will be developed from a sub- 
set of these requirements. Table I summarizes the scope of the working 
model through comparison of Mission Planning Processor and working model 
capabil ities. 

The working model can be executed only in the ACTIVE (i.e., inter- 
active flight activity scheduling) MODE. The EVENT (i.e., generation of 
the long range planning consumables worksheet) MODE does not demonstrate 
interactive capability and will not be implemented in the working model. 
Therefore, Flight Data File 0 (event data) will not be implemented. 

Flight Data Files 1 (minimum data set to operate in the ACTIVE 
MODE) and 2 (usage profiles for each consumables subsystem) will be im- 
plemented in the working model. Flight Data File 3 (data for individual 
elements of the consumables storage and distribution network for each sub- 
system) is not required at this time and will not be implemented in the 
working model. 

The working model will not include the capability to display detailed 
usage rate profiles. These profiles would be used for detailed analysis too 
time consuming for on-line interactive operations. The data will be gener- 
ated and output via the line printer on user request. 
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Table I. Mission Planning Processor Working Model Scope 
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Figure 1 illustrates the working model routine tree. The EVENT MODE 
routines (IV INPUT, FILE ZERO, and EVENT CHART) will not be implemented in 
the working model. The OUTPUT routine associated with detailed usage rate 
profiles (CONSUM HISTORY) will be implemented with printed output not dis- 
play capability. 

2.3 FUNCTIONS 

The working model will perform all the Mission Planning Processor 
functions except display detailed consumables profiles. As noted in Section 
2.2 of this report, these data will be generated and output via the line 
printer on user request. The working model will perform the following 
functions. 

a) Provide user interface through interactive CRT displays 

b) Generate total mission consumable requirements 

c) Act as a scheduler for mission events that affect consumable 
usage 

d) Provide immediate feedback of scheduling conflicts 

e) Provide immediate feedback of consumable usage rate violations 

f) Generate detailed consumable analysis data on user request for 
output on line printer 

g) Store selected generated data in Flight Data Files 1 and 2 on 
user request. 

2.4 ELEMENTS 

The working model will consist of the following elements: 

a) The displays/user interface 

b) The Flight Data Files 1 and 2 

c) The consumables analysis data base 

d) The control and support routines for the ACTIVE MODE 

e) The computational routines 

f) The search, integration, and other utility routines. 


4 


I 


* 

* 

* 



0 ) 

.a 


4-> 

o 

c • 

0) 


01 

-O 


> 


4-> < — 

f— V 

>o 


O 0) 

f— "O 

£ 


c -a 

■r— o 

3 E 

r- 


o 

r- E 

t/l O' 

•f— 


^ Ol 

at c 

3 


3 C 

c •«- 

•r- 

i/i 

• 


4-* L- 

at 


OJ V- 

3 O 

i — 

f* 

c o 

O 3 

•r— 

C 

•r- 3 

t- 

4- 

o 

4-> 

a> 

o 


3 a> 

i- -*= 


4-> 

o ^ 


uj *o 

-Q 

U4 -O 

o <U 

(O "O 

01 

is 

E a> 

3 -M 

O "O 
3 

r— 

to C 

Ll. •— 

z u 

c — 

z u 

=5 c 

O i- 

O c 

a: ■<- 

O CL 

o •<- 

« 

* 

+ 


* 

* 


* 


5 


Figure 1. The Mission Planning Processor 
Working Model Routine Tree 
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2.5 INITIATION 

The working model will be Initiated In the same manner as the Mission 
Planning Processor In the ACTIVE MODE. In the ACTIVE MODE, the Mission 
Planning Processor requires a mission timeline as input. There are two 
methods to introduce the mission timeline into the program as a function 
of where the mission lies in the planning cycle; 

a) The first time the mission is executed, the timeline is entered 
event by event through keyboard entry. Even this mode is semi- 
automatic. Many standardized events (eat and sleep periods, etc.) 
are automatically scheduled as a function of the mission configur- 
ation. 

b) In subsequent executions the mission timeline is entered from 
the FILE 1 data set stored in the Flight Data Files. 

2.6 EXECUTION 

The working model will execute in the same manner as the Mission 
Planning Processor in the ACTIVE MODE. Mission timeline creation or modi- 
fication is accomplished by user input through a set of interactive displays. 
The user may change the start and stop times of mission phases, schedule 
new events, modify existing events, or unschedule existing events. For 
each change in the mission timeline, consumable usage rate blocks are built 
for each consumable subsystem affected by the change. Any scheduling con- 
flicts or rate violations will be fed back to the user and stored in con- 
flict tables for later assessment. 

2.7 OUTPUT 

At this time tn the execution, the user may elect to generate and 
display the following: 

a) A scheduling conflict table listing the time of conflict and 
the conflicting scheduled events. 

b) A rate violation table for each consumable subsystem listing 
the time and rate of the violation and the limit that was 
violated. 

c) A timeline listing scheduled events versus mission time without 
reference to consumables usage. 
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d) The total consumables used and end-of-misslon quantities for 
each consumables subsystem. 

On user request, the detailed profiles (usage rate versus time) for each 
consumables subsystem will be generated via the line printer. 
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3.0 OVERVIEW OF THE TEST PLAN 


The test plan execution will comprehensively exercise the software 
to verify and validate the working model. Verification implies that the 
software will execute and perform the functions specified in Reference 2 
and addressed in Section 2.0 of this report. Validation implies that the 
working model results will be accurate. 

The working model will be tested at the unit, module, and system 
levels. Each software routine (Control and Support, Computational, and 
Utility) will be coued and checked out as a unit. Units will be tested 
as each routine is coded. The units will be coded in a fashion to facili- 
tate module development. Modules are a collection of units that perform 
a specific working model function. Modules will be developed in a "bottom- 
up" order to exercise the more complicated interfaces among Control and 
Support Routines, Computational Routines, Utility Routines, and the 
Consumables Analysis Data Base prior to the less complicated interfaces 
among Control and Support Routines alone. The modules will be integrated 
into a complete program. The program will be tested in a hands-on systems 
environment to verify all proposed working model capabilities and to vali- 
date all working model results. 

The following Sections of this report describe the unit test, module 
test, and systems test procedures. Table II presents a test schedule. The 
test results will be published on completion of testing. 
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Table II. The Mission Planning Processor 
Working Model Test Schedule 
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4.0 UNIT TEST 


The working model software consists of the Control and Support 
Routines, the Computational Routines, and the Utility Routines. Each 
routine will be coded and checked out as a unit. 

The steps to be followed in the coding and checkout of each unit 
are as follows: 

a) Initial coding of the unit 

b) Manual checking to detect and correct obvious errors 

c) Compilation to detect syntax errors 

d) Correction of compiler-detected errors 

e) Recompilation to assure correction of all compiler-detected 
errors . 

A top-down approach was applied to the design of the Mission Planning 
Processor and structured programming techniques will be used in the imple- 
mentation of most of the working model software. One objective of top down/ 
structured methodology is to produce small units of simplified code for ease 
of checkout. Therefore, the above five steps should be sufficient for unit 
testing. 
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5.0 MODULE TEST 


After each unit has been accepted, the routines are to be collected 
into modules. Module construction is dictated by the functional paths 
through the working model illustrated in Figure 1. There are nine modules: 
RATE, ACTION, BUILD, ADD, DELETE, FLIGHT, PLAN, OUTPUT, and EXEC. The 
module name implies the controlling routine. Modules will be developed 
in a bottoms-up order to exercise the more complicated interfaces among 
Control and Support Routines, Computational Routines, Utility Routines, and 
the Consumables Analysis Data Base prior to the less complicated interfaces 
among Control and Support Routines alone. 

A driver will be written to test each module. The RATE, ACTION, 
BUILD, ADD, DELETE, and FLIGHT modules can be completely tested in a batch 
mode environment. The PLAN, OUTPUT, and EXEC modules can only be partially 
tested by batch mode because of their "interactive" requirements. There- 
fore, the PLAN, OUTPUT, and EXEC module testing will be completed during 
the hands-on system test. 

The modules are listed in Table III and described in the following 
subsections. The descriptions address the module objectives and the Control 
and Support Routines that make up each module. Although not directly ad- 
dressed, the appropriate Computational and Utility Routines are included in 
each module. 

5.1 THE RATE MODULE 

The RATE module is the heart of the working model and consists of 
the RATE and CONSTRAINT routines. The RATE module constructs the consum- 
ables rate tables for each subsystem affected by a scheduled or unscheduled 
event and checks for rate constraint violations. These rate tables are 
internal tables used for constraint checking and consumables usage inte- 
gration. The RATE module includes several utility routines to manipulate 
the consumables usage rates for each activity as stored in the Consumables 
Analysis Data Base. 

A driver will be constructed to test all functions of the RATE 
module by itself. Then RATE module testing will continue because the RATE 
module is the basic part of the ACTION and BUILD modules. 

11 


» •• • \ 


i 


Table III. The Mission Planning Processor 
Working Model Modules 


MODULE 

UNITS 

FUNCTIONAL FLOW* 

RATE 

RATE Routine 

37/5-122 


CONSTRAINT Routine 

23/5-48 

ACTION 

ACTION Routine 
RATE Module 

15/5-14 


CONFLICT ROUTINE 

21/5-36 


SPECIAL Routine 

39/5-137 

BUILD 

BUILD Routine 

17/5-25 


SPECIAL Routine 
RATE Module 

39/5-137 


CONFLICT Routine 

21/5-36 

ADD 

ADD Routine 

16/5-19 


POOL Routine 

35/5-117 


SEQUENCE Routine 

38/5-130 


ACTDIS Routine 
ACTION Module 

14/5-10 

DELETE 

DELETE Routine 

24/5-59 


SEQUENCE Routine 

38/5-130 


ACTDIS Routine 
ACTION Module 

14/5-10 

FLIGHT 

FLIGHT Routine 
DELETE Module 

29/5-79 


SPECIAL Routine 
RATE Module 

39/5-137 


*Figure/Page number of the Control and Support Routine flow chart in 
Reference 2. 
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Table III. The Mission Planning Processor 

Working Model Modules (Concluded) 


MODULE 

UNITS 

FUNCTIONAL FLOW* 

PLAN 

PLAN Routine 
ADD Module 
DELETE Module 
FLIGHT Module 

34/5-103 


LINECK Routine 

32/5-91 


DISPLAY Routine 

25/5-63 

OUTPUT 

OUTPUT Routine 
FILE STORE Routine 
TIMELINE Routine 

33/5-95 


DISPLAY Routine 

CONSUM HISTORY Routine 

CONSUM QUANTITIES 
Routine 

25/5-63 

EXEC 

EXEC Routine 
OUTPUT Module 

13/5-5 


INITIAL Routine 
BUILD Module 
PLAN Module 

30/5-85 


FILE ONE Routine 

27/5-72 


*Figure/Page number of the Control and Support Routine flow chart in 
Reference 2. 
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5.2 THE ACTION MODULE 


The ACTION module consists of the ACTION routine, the RATE module, 
the CONFLICT and SPECIAL routines. The ACTION module will construct the 
File 1 schedule data set, detect scheduling conflicts, construct consumables 
rate tables, and detect consumables rate violations. Common block and on- 
orbit activities will be input to construct a pseudo Flight Data File 1. 

5.3 THE BUILD MODULE 

The BUILD module consists of the BUILD and SPECIAL routines, the 
RATE module, and the CONFLICT routine. The BUILD module reconstructs the 
scheduling conflict table, the consumables rate tables, and the rate 
violation table from a previously stored Flight Data File 1. A pseudo 
Flight Data File 1, including the comnon blocks and on-orbit activities re- 
quired for a skeleton mission will be used as input to the BUILD module. 

5.4 THE ADD MODULE* 

The ADD module consists of the ADD, POOL, SEQUENCE, and ACTDIS 
routines and the ACTION module. The ADD module schedules an activity by 
establishing the activity number, setting the Flight Data File 1 cross 
reference parameters, and calling the ACTION module to complete the sched- 
uling affects. Common block, single on-orbit activities, and cyclic on- 
orbit activities will be scheduled to test the ADD module. 

5.5 THE DELETE MODULE* 

The DELETE module consists of the DELETE, SEQUENCE, and ACTDIS routines 
and the ACTION module. The DELETE module unschedules an activity by erasing 
its effects for the Flight Data File 1 cross reference parameters, and calling 
the ACTION module to complete the unscheduling. Common block and single on- 
orbit activities will be unscheduled to test the DELETE module. Cyclic acti- 
vities must be deleted one at a time the same way as single on-orbit activities. 


*The DELETE and ADD modules are used in sequence to modify a scheduled activity. 
This capability will be verified during the system test. 
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5.6 THE FLIGHT MODULE 

The FLIGHT module consists of the FLIGHT routine, the DELETE module, 
the SPECIAL routine, and the RATE module. The FLIGHT module updates the common 
blocks if any flight phase times are changed during scheduling by calculating 
new phase times, and calling the RATE module to modify the scheduled usage 
rate data. If the on-orbit flight time is shortened, the FLIGHT module calls 
the DELETE module to erase all previously scheduled activities beyond the new 
end-of -flight time. 

5.7 THE PLAN MODULE 

The PLAN module consists of the PLAN routine, the ADD, DELETE, and 
FLIGHT modules, and the LINECK and DISPLAY routines. The PLAN module provides 
the interactive capability within the working model. The PLAN module acts 
as a middle manager calling on the other routines and modules to perform the 
basic working model functions of scheduling, modifying, or deleting consum- 
ables related flight activities. The capabilities of the PLAN module can 
only be completely tested during the hands-on system test. 

5.8 THE OUTPUT MODULE 

The OUTPUT module consists of the OUTPUT, FILE STORE, TIMELINE, DISPLAY, 
CONSUM HISTORY, and CONSUM QUANTITIES routines. The OUTPUT module provides 
the option to display, print, and store selected data generated by the working 
model. Only the CONSUM HISTORY capability to print detailed usage rate 
versus time data will be bench tested. The display and store capabilities 
will be tested during the hands-on system test. 

5.9 THE EXEC MODULE 

The EXEC module consists of the EXEC routine, the OUTPUT module, the 
INITIAL routine, the BUILD and PLAN modules, and the FILE ONE routine. The 
EXEC module controls the working model and calls other modules, at user 
request, to execute the user directed working model functions. The EXEC 
module can only be completely tested during the hands-on system test. 
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6.0 SYSTEM TEST 


On completion of module testing, the modules will be integrated 
into the working model. The system tests will be conducted in a hands- 
on environment on the UNIVAC 1110 EXEC 8 using test cases designed to ver- 
ify all proposed working model capabilities and to validate all working 
model results. 

6.1 VERIFICATION 

At least four different cases will be designed and executed to test 
the total working model system. The test cases include, but are not limited 
to the following: 

Case #1 - A cold start exercising interactive scheduling 

Case #2 - A restart exercising interactive scheduling 

Case #3 - Exercise all schedule conflict possibilities 

Case #4 - Exercise all rate violation possibilities. 

Other system test cases may evolve from module testing. The results ex- 
pected from each systems test case will be calculated before execution. 

The test cases should verify all proposed working model capabilities. 

Those capabilities are: 

Initiation 

• That a cold start produces a skeleton profile before any 
activity is interactively scheduled. 

• That a restart will reproduce a previously saved profile 
including all scheduling conflicts, rate tables, rate 
violations, and output displays before any other activity 
is interactively scheduled. 

Execution 

t That the user interface displays accept, transfer, and dis- 
play data correctly. 

• That the user interface displays sequence properly. 

t That flight phase times can be altered and the changes pro- 
perly reflected in all affected data sets. 
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• That the effects of all activities scheduled beyond a new 
(shortened) flight end time will be erased. 

• That all single and cyclic activities can be added to, 
modified on, or deleted from a skeleton profile (i.e.. Cold 
Start) or a scheduled (i.e.. Restart) profile. 

• That a scheduling conflict warning is displayed on all pos- 
sible combinations of activity-to-activity conflicts. 

• That a rate violation warning is displayed for all consumables 
subsystems when a rate violation occurs. 


Output 

§ That all output displays (Scheduling Conflict, Rate Violation, 
Timeline, Consumables Quantities) can be properly generated 
for all consumables subsystems. 

• That detailed profiles of consumables usage rate versus time 
can be generated for printed output for all subsystems. 

• That a warning will be displayed if the user attempts to end 
execution prior to saving a Flight Data File 1. 

• That Flight Data File 1 can be generated and saved at the end 
of an execution. 

6.2 VALIDATION 

On completion of system test verification, at least five different 
cases will be executed to validate the results of the working model. The 
cases encompass the 0FT2 through 0FT6 flights. 

The activity timeline and consumables requirements for each of these 
flights have been generated by NASA/JSC/MPAD using detailed models and docu- 
mented in References 3, 4, and 5. The activity timeline for each flight 
will be scheduled using the working model and the consumables requirements 
generated by the working model will be compared to the documented MPAD 
results. The criteria used to validate the working model results for each 
consumables subsystem are as follows: 


17 



EPS 


§ If valid, the working model generated energy requirement 
(KWH) should approximately equal the MPAD generated energy 
requirements. The usage rates are derived from the same 
source and the processing is simply rate multiplied by time. 

• The quantity of EPS cryo required, however, will differ be- 
cause of the processing differences between the simplified 
working model and the MPAD detailed models. If valid, the 
difference should be within ±5 percent. 

QMS and RCS 

• The working model generated OMS and RCS propellant require- 
ments will differ from the MPAD generated requirements. The 
working model utilizes an average usage rate instead of a 
flight specific usage rate used by the MPAD detailed models. If 
valid, the difference should be within +5 percent. 

ECLSS 

• If valid, the working model generated ECLSS consumables (H 2 , 

02. LiOH, and H 2 O) requirements should approximately equal 
the MPAD generated requirements. The usage rates are derived 
from the same source and the processing is simply rate multi- 
plied by time. 

APU 


• If valid, the working model generated APU consumables (Fuel 
and H 2 O) requirements should approximately equal the MPAD 
generated requirements. The usage rates are derived from 
the same source and the processing is simply rate multiplied 
by time. 
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